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ABSTRACT 

Job scheduling is a deceptively complex subfield 
of computer science. The highly combinatorial na- 
ture of the problem, which is NP-complete in 
nearly all cases, requires a scheduling program 
to intelligently traverse an immense search tree 
to create the best possible schedule in a minimal 
amount of time. In addition, the program must 
continually make adjustments to the initial 
schedule when faced with last-minute user re- 
quests, cancellations, unexpected device failures, 
etc. A good scheduler must be quick, flexible, and 
efficient, even at the expense of generating 
slightly less-than-optimal schedules. 

The Space Communications Scheduler (SCS) is 
an intelligent rule-based scheduling system de- 
veloped at GE’s Advanced Technology Laborato- 
ries. SCS is an adaptive deadline scheduler 
which allocates modular communications resourc- 
es to meet an ordered set of user-specified job re- 
quests on board the NASA Space Station. SCS 
uses pattern-matching techniques to detect po- 
tential conflicts within a schedule, then resolves 
these conflicts through algorithmic and heuristic 
means. As a result, the system generates and 
maintains high-density schedules without relying 
heavily on backtracking or blind search tech- 
niques. SCS was designed to allocate communica- 
tion devices on board the Space Station, but its 
general-purpose scheduling strategy is suitable 
for many common real-world applications. 

1.0 INTRODUCTION 

’’Scheduling' is a term very familiar to most peo- 
ple. Personal schedules are routinely made and 
revised; it is a task so common that few people 
think about the cognitive actions involved in its 
performance. Yet, the seemingly simple act of 


scheduling, which can be loosely defined as allo- 
cating the resources necessary to perform a set of 
jobs over a specific time interval, is one of the 
more complex problem areas of computer science. 

Two general classes of scheduling problems exist: 
precedence constrained and deadline . Precedence 
constrained scheduling (sometimes called simply 
constraint scheduling) is very closely related to 
classical computer planning problems. In its most 
basic form, constraint scheduling generates an 
agenda for performing subtasks of a specified job, 
given a partial ordering of the subtasks and a 
deadline for completing the job. Garey and John- 
son (Garey and Johnson, 1979) illustrate con- 
straint scheduling with the example of a college 
freshman building a four-year course plan. Be- 
cause certain courses are required for gradua- 
tion, and because most of these courses have pre- 
requisites of their own, developing an 
appropriate schedule is, as every college student 
knows, a non-trivial task. 

Deadline scheduling (sometimes called interval, 
appointment, or timetable scheduling) is a some- 
what more familiar problem class. Here, the goal 
is to create an optimal timetable for the execution 
of a set of jobs over a specific interval of time, giv- 
en a finite set of available resources and a set of 
acceptable release times (earliest start times), 
deadlines (latest completion times), and priorities 
for each job. Common real-world examples in- 
clude a doctor’s receptionist scheduling patient 
appointments and a computer’s operating system 
scheduling the execution of batch programs. 
What actually constitutes an "optimal” schedule 
varies from application to application. In the first 
example, an optimal schedule would be one that 
allows the maximum number of appointments, 
while in the second, it might maximize the sum 
of the priorities of the executed programs. I 


1. Many application areas fall into both scheduling classes. Engineers at a car manufacturing plant, for example, 
must make use of both constraint scheduling (deciding the optimal order for assembling the parts of a car) and 
deadline scheduling (allocating the personnel and resources to perform each task at the appropriate time). 
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Both constraint and deadline scheduling are NP- 
complete in virtually all non-trivial cases (Garey 
and Johnson, 1979), which forces all automated 
scheduling systems to rely heavily on heuristic 
search techniques. Unfortunately, certain real- 
world scheduling considerations make good 
schedules extremely difficult to generate, even 
heuristically. The resources available to perform 
the jobs may be very limited or they may not be 
shareable between jobs. Jobs may have varying 
durations or variable release times, they may be 
uninterruptible, or they may not be permitted to 
run concurrently with other jobs. In addition, a 
scheduler is not necessarily finished after the ini- 
tial schedule is made. Unforseen circumstances 
often arise during job execution time, such as a 
last-minute emergency request or an unanticipat- 
ed equipment failure, that require the scheduler 
to make "on-the-fly" adjustments. 

1.1 Related Research 

Because of the very diverse nature of scheduling 
problems, as well as their inherent intractability, 
the goal of computer science researchers is not to 
create one general-purpose program that can 
handle every conceivable scheduling problem, nor 
to create a program that guarantees optimal 
schedules instantaneously. Rather, the goal is to 
create programs that generate near-optimal 
schedules, in a reasonable amount of time, for 
one specific subclass of scheduling problems. 

Most recent research has concentrated on Job- 
Shop Scheduling (JSS), a general subclass of 
problems within the domain of Operations Re- 
search (Martin and Pling, 1978; Marcus, 1984). 
The goal of most JSS systems is to develop near- 
optimal schedules for manufacturing or industri- 
al facilities where slight improvements in sched- 
uling efficiency may translate into huge amounts 
of savings to a company. Another popular re- 
search area is the development of schedulers for 
computer operating systems (OS) (Deitel 1984; 
Tanenbaum, 1987). Many OS textbooks include a 
chapter on scheduling; Deitels An Introduction to 
Operating Systems (Deitel 1984) contains a good 
set of goals for an OS scheduler. 


Within the field of Artificial Intelligence (AI), 
scheduling is part of the Planning Systems do- 
main (Nillson, 1980). Much of this research is con- 
cerned with modeling the real-world planning en- 
vironment and representing the effects that 
certain actions have on the model. Deadline sched- 
uling is often represented as the lowest level on 
the planning tree, performed only after goals are 
identified and task sequences are determined. So- 
phisticated planning systems will consider dead- 
line scheduling restrictions as part of the overall 
plan generation process (Hayes-Roth et al., 1979). 

Fox and Kempf (1985) have studied the dual prob- 
lems of computational complexity and executional 
uncertainty on job-shop scheduling domains. 
From this, they have defined two basic principles 
for building an efficient scheduler. The "Principle 
of Least Commitment” states that a scheduler 
should never commit a job to a specific time inter- 
val or resource set until there is a good reason to 
do so. The “Principle of Opportunism” states that 
a scheduler should take advantage of all available 
opportunities to reduce its search space. 

1.2 Terminology 

A job (also called a service) is a single, indivisi- 
ble, real-world task to be performed within a 
specified time interval. The actual nature of a job 
varies from application to application. To a doc- 
tor, a job may be one consultation session with a 
patient. To a factory line worker, a job may be 
assembling ten electric motors by a certain dead- 
line. Associated with each job are a priority , a set 
of preconditions that must be met before the job 
may begin (also expressible as set-up time), the 
time constraints for scheduling the job, and a set 
of resources needed to perform the job. 

A resource is anyone or anything available for use in 
the execution of a job, such as a person, a work area, 
a tool, or a raw material. Like jobs, resources are as- 
sumed to be indivisible units for scheduling purpos- 
es. The maximum number of jobs that a resource 
can support at one time is known as its capacity . A 
dedicated resource has a capacity of one, while a 
shareable resource has a capacity greater than one. 2 


2. Note that shareability and indivisibility are not mutually exclusive terms. A mainframe computer is shareable 
in the sense that more than one user may be logged in at any given time. It is indivisible in that a user does not 
request the "left half' or the "bottom one-third" of the computer when reserving CPU time. Similarly, a box of 
ten identical screwdrivers may be thought of as ONE shareable, indivisible resource with a capacity of TEN jobs. 
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The number of jobs actively being supported by a 
resource at any given time is known as the re- 
source’s load. An idle resource is one with a load 
equal to zero. A free (or available) resource has a 
load less than its capacity, while a busy resource 
has a load equal to its capacity. An overloaded 
resource has a load greater than its capacity and 
indicates that an error condition is present in a 
schedule. The jobs competing for an overloaded 
resource are said to be in conflict. 

A scheduler (whether human or machine) takes 
a description of the set of jobs to be performed 
and the resources available to perform them, and 
produces a schedule which maps resources to 
jobs. An allocation is when one resource is re- 
served for one job over one interval of time, and 
a supported job is one which has reserved all of 
the resources necessary for its execution. Finally, 
a schedule is any mapping of resources to jobs. 

2.0 SPACE STATION COMMUNICATIONS 

GE's Government Communications System Divi- 
sion (GCSD) is a member of the McDonnell- 
Douglas team awarded NASA's Space Station 


Work Package II. GCSD's task is to develop the 
Space Station's Communications and Tracking 
System (C&TS). 

C&TS will be comprised of a number of subsys- 
tems, each handling a specific class of communi- 
cations (see Figure 2-1). The Space-To-Space 
Communications (STSC) Subsystem, for example, 
supports links between the Space Station and 
non -terrestrial sources (satellites, the Space 
Shuttle, etc.). All subsystems consist of a set of 
modular communications devices that can be con- 
figured in a variety of ways, depending on the 
Space Station's current needs. A set of devices 
that supports a single communication link is 
called a string; at any given time, a subsystem 
may have several (or zero) active strings. 

All C&TS subsystems are managed by the Con- 
trol and Monitoring (C&M) Subsystem, which is 
responsible for allocating communications re- 
sources, monitoring the performance of on-line 
devices, diagnosing equipment failures, and tak- 
ing whatever actions are necessary to maintain 
error-free communication links. GE engineers, as 
part of an ongoing IR&D project, have been eval- 
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Figure 2-1. 


Architecture of Communications and Tracking System (C&TS). 
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uating the feasibility of integrating two knowl- 
edge-based systems within C&M: the Space Com- 
munications Expert (SCE) and the Space Com- 
munications Scheduler (SCS). 

GE's Advanced Technology Laboratories (ATL) 
developed SCE in 1987 as an embedded expert 
system designed to monitor and maintain 
strings within the STSC Subsystem. SCE allo- 
cates new strings on command, then evaluates 
data from various sources, such as external 
test procedures, device status reports, and the 
global Space Station database, to ensure that 
the string is operating normally. When anoma- 
lies are detected in a communication link (corn- 
link), SCE isolates and replaces the device 
causing the problem. In 1988, GCSD developed 
an expanded version of SCE, the Prototype In- 
telligent Space Communications Expert System 
(PISCES). PISCES extends SCE to include both 
strings and partial device failures in the 
Space-To-Ground Communications (STGC) Sub- 
system. 

SCS and PISCES were conceived as cooperating 
expert systems that form the "brain M of C&M. 
SCSs role is to allocate and schedule C&TS de- 
vices, and then transfer control to PISCES which 
assembles and maintains the resulting strings. 
When PISCES recognizes a device failure, it noti- 
fies SCS, which in turn adjusts its schedule ac- 
cordingly and specifies an available replacement 
device to PISCES. 

2.1 SCS Scheduling Domain 

C&TS is a relatively standard deadline schedul- 
ing domain in which "jobs" correspond to individ- 
ual communication links (called "services*'), and 
"resources" are the modular communication de- 
vices used to create strings (transceiver-modems, 
switches, fiber-optic links, antennas, etc.). 

As with SCE, the first-year development effort of 
SCS concentrated solely on the STSC Subsystem. 
A string within STSC typically consists of five 
interconnected devices (see Figure 2-2). Trans- 
mitted signals first travel through a Baseband 
Signal Processor (BSP) which connects STSC 
with the many data busses on board the Space 
Station. The Transceiver-Modem (XMODEM) 
modulates this signal and sends it through an 



Figure 2-2. Standard Space-To-Space 
Communications String. 


outgoing Intermediate-Frequency Switch (IF- 
SWITCH) to a specific Antenna Mounted Equip- 
ment (AME) from which it is transmitted. Re- 
ceived signals traverse the same path in the op- 
posite direction, except that an incoming IF- 
S WITCH is used. 

The two critical devices on an STSC string are 
the Transceiver-Modem and the Antenna. Select- 
ing an XMODEM forces the selection of the BSP 
and IF-SWITCHes because they are hardwired 
together. The four types of AMEs are OMNI, 
AIR-LOCK, SERVICE-BAY, and PARABOLIC. 
They are located at various fixed spots on the 
outside of the Space Station. To allocate an 
STSC string, one must allocate an XMODEM 
(any operational one will do) and an AME of the 
appropriate type in the appropriate location. 

Figure 2-3 shows the XMODEMs and AMEs of 
STSC represented as SCS tables. 
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pi = (XMODEM-AI, 100, I) 

p2 = (XMODEM-A2, 100, I) 

p3 = (XMODEM-A3, 100, I) 

p 4 = (XMODEM-BI, 100, I) 

p5 = (XM0DEM-B2, 100, I) 

p6 = (XM0DEM-B3, 100, 1) 

p7 - (OMNI-AME- I, 80, 3) 

p8 = (0MN1-AME-2, 80,3) 


p9 = (OMNI-AME-3, 80,3) 
p I 0 = (OMNI-AME-4, 80,3) 
p| I = (AIR-LOCK-AME-I, 80, 3) 
p 1 2 = (AIR-LOCK- AME-2, 80,3) 
p 1 3 = (GIMBAL-AME-I, 80, I) 
pl 4 - (GIMBAL-AME-I, 60, I) 
p 1 5 - (SERVICE-AME- I, 80,3) 


xl = (XMODEM, 

(XMODEM-AI , XM0DEM-A2, 
XM0DEM-A3, XMODEM-BI, 
XM0DEM-B2, XM0DEM-B3) ) 

■Q = (OMNI-AME -PORT, 

(OMNI-AME- I , OMNI-AME-3) ) 
x3 - (OMNI-AME -STARBOARD, 

(OMNI -AME-2, OMNI-AME-4) ) 


Figure 2-3. Resource tables and table classes for C&TS. 


3.0 SPACE COMMUNICATIONS 
SCHEDULER 

SCS is a rule-based scheduling system developed 
by GE's Artificial Intelligence Laboratory in 
Moorestown, NJ. SCS was designed to allocate 
and schedule modular communications equipment 
on board the NASA Space Station, automatically 
making adjustments during job execution time 
when faced with unexpected device failures or 
last-minute user requests. It combines algorithmic 
and heuristic search techniques, sophisticated 
pattern-matching capabilities, and a flexible 
scheduling strategy adaptable to many different 
applications. SCS was implemented using Infer- 
ence's Automated Reasoning Tool (ART™) expert 
system shell augmented with custom LISP and C 
code; it runs on a Digital™ VAX computer. 

SCS addresses deadline scheduling problems 
char- acterized by: 

1. Continuous , indivisible jobs — Once started, a 
job will not be preempted before completion. 

2. Negligible or constant set-up times between 
jobs — Set-up times are usually a trinary 
function of two jobs and one resource, yielding 


a time. For example, SETUPTIME (A,B,R) = 
10 means that it will take 10 minutes to re- 
set" resource R between the end of job A and 
the start of job B. SCS requires that all set- 
up times are either negligible (in which case 
they can be ignored) or relatively constant (in 
which case they can be automatically added to 
the duration of each assignment). 

3. Low-capacity resources — Each resource has a 
relatively low capacity, generally five jobs or 
less. SCS takes approximately 1.5 times long- 
er to schedule a (X+l)-capacity resource than a 
X-capacity one. 

4. Partial order of job prioities — Each job has 
its own scheduling priority, and no job may 
preclude a higher-priority job from being 
scheduled. In other words, it is better to 
schedule one job of priority 100 than 10 jobs 
of priority 90. 

The subclass of scheduling problems handled by 
SCS is actually very common. Virtually any do- 
main requiring "appointments" — from a doctor s 
office, to dinner reservations, to library books, to 
a college computer terminal room, to communica- 
tions equipment aboard the Space Station — is a 
domain in which SCS is applicable. 
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3.1 SCS Data Structures 

Within SCS, jobs are represented by service- 
requests, resources by tables, and allocations by 
blocks. Service-requests and tables, along with 
certain scheduling parameters, make up the input 
to SCS. No two service-requests or two blocks 
may be exactly alike. The lone output of the sys- 
tem are the blocks that make up the schedule. 
This section contains the formal definitions of 
the input and output specifications of SCS. 

All SCS time specifications are in military format 
with discrete one-minute increments. A time in- 
terval is specified as an ordered pair (tj, t^), in- 
clusive of its startpoint but not inclusive of its 
endpoint. For example, "(0800, 0900)" specifies 60 
one-minute units of time, the first unit beginning 
at 8:00 AM and the 60th beginning at 8:59 AM. 
While this is a somewhat inelegant convention, 
no perfect way exists to model time as an or- 
dered set of discrete elements (Allen, 1983). 

3.1.1 Service-Requests 

A service-request is a 4-tuple, 

a = (j, 7t, T, p) 

E = (*^lj •••) cr m } 

J = (j(crj) I l<i<m} 

where j is the job represented by a; n is an or- 
dered pair, (rcp.Tti), specifying priority; T is a set 
of 4-tuples, T = {Ti,T2,...J, Ti = (t 0 , (A+,A.), 
MINA, d) representing the time constraints; and 
p is the resource set, (pl,p2v), required to per- 
form s. 

Each service-request corresponds to exactly one 
job, jej. However, a job may be represented by 
multiple service-requests, each with a different n, 
T, and/or p. Once a job is successfully scheduled 
by SCS, all alternative requests for that job are 
automatically deactivated. 

Jtp and Ji; are called the scheduling priority and 
inertia value of a. Scheduling priority is used 
only during the initial scheduling phase, and it 
represents the relative importance of a in com- 
parison to other service-requests. If and when a 
job is successfully scheduled, the inertia value 
specifies how difficult it is to "bump" that job 
during the rescheduling phase. 


T, the time constraint for s, is itself a set of 4- 
tuples. Each Tje T consists of a start time (t s ); the 
allowable negative and positive offsets from the 
start time, (A_,A+); a boolean flag (MINA) which, 
when set, specifies that the request should be 
scheduled as close as possible to t s ; and the job’s 
duration (d). In standard terminology, the re- 
lease time for o is (t<j - A.) and the deadline for a 
is (t<j + A+ + d). Each Tj in T signifies an equally 
acceptable time interval for scheduling the job. 

Finally, p specifies the resource set for a. Be- 
cause resources are represented as "tables" with- 
in SCS, p is expressed as a nonempty set of table 
names or table classes (see Section 3.1.2). For a 
to be successfully scheduled, all tables in p must 
be available at the specified time; otherwise, no 
resources are allocated and <r is deactivated. 

An example of how to specify SCS service- 
requests is given in Figure 3-1. 

3.1.2 Tables a nd Table Classes 

A table is a triplet such as 

P = (r, *p* X) 

P = lpi» •••) Pn) 

R = {r(pi) I l<i<n} 

where r is the resource represented by p, Tip its 
reduction priority, and X its capacity. Every re- 
source, rj, has exactly one corresponding table, 
Pi, and vice versa. 

The reduction priority, Tip, is used during the lat- 
ter stages of scheduling when SCS assigns a fixed 
start time and resource set to each job. The higher 
a table's reduction priority, the more likely its cor- 
responding resource will be used continuously in 
the final schedule. X represents the resource’s ca- 
pacity and is specified as a positive integer. 

For efficiency, similarly used resources can be 
collectively expressed as table classes. Whenever 
a service-request specifies a table class, T, (P^T), 
in its resource set, SCS will automatically gener- 
ate N new requests (N = I T I ) with the table 
class replaced by each x e T. This allows a user 
to issue general resource requests such as "one 
room large enough to hold 20 people" rather than 
"Either Room B or Room C or Room D or..." 
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THE JOB; My office building has three conference rooms: 

Room A (capacity: 10 people) 

Room B (capacity: 15 people) 

Room C (capacity: 20 people) 

Each room can be reserved for one conference at a time. 1 need to reserve one room and one 
of our three (identical) vugraph projectors for a staff meeting sometime tomorrow. 

My first choice (priority 100) is to hold the meeting in the morning. It may start at exactly 8:00 AM, or 
anytime between 9:00 and 9:30. It will run for three hours, and there will be 20 attendees. 

Our second choice is to have the meeting at 1 :00 in the afternoon. It can start as late as 
1:30, if necessary, but I'd prefer if it began within 10 minutes of 1:00. Only 15 people can 
attend an afternoon meeting, and it will last only 2 1/2 hours. 

In either case, once the meeting is scheduled it should not be bumped in favor of any job 
with a priority of less than 150. 


THE IA2LE1 AND TABLE CLASSES: 


■ 

p,= (ROOM_A, 100, 1) ■ 

at (STAFF MTG, , 

(100,50) i 

i p:= (ROOM_B, 100, 1) | 

((800, (000, 000), FALSE, 300), 

p?=(ROOM_C, 100, 1) i 

(900, (000, 030), FALSE, 300)), 

! p4= (VUGRAPH, 80, 3) 1 

(CROOM_20, VUGRAPH)) i 

| x, = (CROOM_10, (ROOM_A, ROOM_B, ROOM_C)) I 

<* (STAFF_MTG, « 

i T: = (CROOM_15, (ROOM_B, ROOM_C)) 1 

(80, 70) ] 

i T} — (CROOM 20, (ROOM G)) \ 

((1300, (000, 030), TRUE, 230)), , 


(CROOM 15, VUGRAPH)) i 


Figure 3-1. Service-request and table specifications for the "Staff Meeting” scenario. 


An example of how to specify SCS tables and ta- 
ble classes is shown in Figure 3-1. Note that the 
capacity of each conference room is 1, not 10, 15, 
or 20. While a room may be large enough to seat 
up to 20 people, it still can support only one 
meeting at a time. 

3.1.3 Blocks 

The output from SCS is a set of blocks representing 
the mapping of tables to service-requests (i.e., re- 
sources to jobs). Blocks are expressed as a 5-tuple: 

P = (a, T a , P a , t w , tc) 

B = (Pi, Pp) 

where a is the service-request associated with p, 
T a (e T(a)) is the time constraint of a 
corresponding to the block 
P a (e P(a)) is the set of tables in which 
the block is present 
t w is the window of time for the block 
t c is the critical time of the block. 


The window of a block, t w , is expressed as an or- 
dered pair (t ws , t we ). The length of the window 
is at least as long as the duration (d) of T a . In 
addition, the window is a subinterval of T a s re- 
lease time and deadline. 

The critical time, t c , specifies the subinterval of t 
in which the block, if chosen for the final sched- 
ule, will definitely be in use. It, too, is expressed 
as an ordered pair, (t C s, t ce ), where t cs = t we - d 
and t C e = t ws + d. If the length of t w is greater 
than or equal to two times the block's duration, 
d, then the block has no critical time, and t c is 
expressed simply as "NONE." 

To better illustrate critical times, consider a ser- 
vice-request that specifies a release time of 800 
hours, a deadline of 1100 hours, and a duration 
of 200 hours. Such a request could be scheduled 
from either 800 to 1000, or from 900 to 1100, or 
from 845 to 1045, etc. No matter which start and 
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end times are chosen, however, the request must 
be in execution between 900 and 1000. Therefore, 
the block generated from this request would have 
t w (p) = (800, 1100) and t c (p) = (900, 1000). 

The specific types of blocks found in SCS include 
the following: A fixed block is one in which t w = 
t c ; that is, its window length is exactly equal to 
its job’s duration. A critical block is one in which 
t c * "NONE"; similarly, a noncritical block has 
t c = "NONE”. A split block is a special type of 
noncritical block in which (t we - t ws ) = 2d. Two 
blocks are alternatives if they share a common 
job (Pi * p2 & j(Pi) = j(P2))» while a unique block 
is one with no alternative. 

A generalized definition of schedule can now be 
given as "any conflict-free set of blocks." A sched- 
ule is called complete if it consists of only fixed, 
unique blocks. Schedules that are not complete 
are partial (that is, they contain at least one 
block which is nonunique and/or nonfixed). Par- 
tial schedules are converted to complete ones by 
assigning fixed start times and resource sets to 
each job and removing superfluous blocks; this 
process is called reduction. Examples of SCS 
blocks are given in Figure 3-2. 

3.1.4 Notational Conventions 

Notational conventions for representing tables 
and blocks can be defined pictorially. Conflicts, 
overloaded resources, block alternatives, etc., are 
much more noticeable when displayed graphical- 
ly rather than as a textual list of n-tuples. 

Figure 3-3 introduces the notational conventions 
used to represent blocks and tables. The two dis- 


tinct formats for representing blocks are stan- 
dard notation and critical notation. Standard 
notation , which highlights duration and delta 
time, is best suited for displaying SCS schedul- 
ing states. Critical notation highlights a block’s 
critical time (or lack thereof) and is useful for 
identifying conflicts and overloads. 

Figure 3-4 shows two blocks, Pi and p2, graphed 
within table p3 ("ROOM_C"), using critical nota- 
tion. 

3.2 SCS Operation 

The two operational phases of SCS are the 
Scheduling Phase and Rescheduling Phase. Its 
five distinct modes of execution are called Pre- 
Processing, Placement, Allocation, Completion, 
and Deallocation. Section 3.2.1 discusses the 
scheduling strategy used by SCS in each of its 
various system states. 

3.2.1 Scheduling Phase vs. Rescheduling 

Pha se 

During the Scheduling Phase, the SCS gener- 
ates an initial schedule from a static set of ser- 
vice-requests and tables. Then, SCS switches to 
the Rescheduling Phase in which additions and 
changes to the initial schedule may be made. Al- 
though they are mutually exclusive, both phases 
share a common set of rules, data structures, 
computational states, search strategies, and ter- 
minology. The most important distinction be- 
tween the two is that in the Scheduling Phase 
SCS creates a new schedule, while in the Re- 
scheduling Phase SCS adjusts an existing 
schedule. 


Scheduling phase is run once, and only 
once, for any given set of input. After the 
initial schedule is generated and has been 
accepted by the user, SCS automatically 
switches to the Rescheduling Phase. Note 
that the Scheduling Phase operates on a 
static set of input data. If the user wish- 
es to make any changes to the input set 
while SCS is actively generating a sched- 
ule, two choices are available: either wait 
until for Rescheduling Phase and make 
the changes then, or halt the system, ad- 
just the input, and start the system over. 


B = 


bi = {(7i, 1, 

(ROOM_C, VUGRAPH), 
( 800 , 1100 ), 

( 800 , 1100 ) ) 

fc>3 = (<72, 1 , 

(ROOM_C, VUGRAPH), 
( 1300 , 1600 ), 

( 1330 , 1530 ) ) 


b2 = (cji, 2, 

(ROOM_C, VUGRAPH), 
( 900 , 1230 ), 

( 930 , 1 200 ) ) 

tM = (<72, 1 , 

(ROOM_B, VUGRAPH), 
( 1300 , 1600 ), 

( 1330 , 1530 ) ) 


Figure 3-2. SCS blocks corresponding to the "Staff 
Meeting" scenario. 
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Figure 3-3. Notational conventions. 



Figure 3-4. Graphing table ROOM_C in the "Staff 
Meeting" scenarios. 


SCS is normally inactive during the Reschedul- 
ing Phase, and returns to an active state only 
when the set of service-requests (£) or tables (P) 
changes. The important feature of the Reschedul- 
ing Phase is that it makes nondisruptive schedul- 
ing adjustments, meaning that it will keep the 
original schedule as intact as possible during re- 
scheduling. This feature is particularly important 
for the Space Station because any changes in the 
C&TS schedule may have a ripple effect on the 
schedules of other systems (e.g., payload deploy- 
ment, laboratory experiments, astronauts' per- 
sonal agendas, etc.). 

SCS's projected role for the Space Station is its 
running in the Scheduling Phase once per eve- 


ning to generate the C&TS schedule for the next 
day. SCS remains active in Rescheduling Phase 
throughout the day to handle last-minute ser- 
vice-requests, device failures, newly activated re- 
sources, etc. 

3.2.2 Modes of Execution 

SCS utilizes a five-step scheduling strategy, with 
each step known as a mode of execution. The SCS 
system state can be specified as an ordered pair 
of phase and mode: 

S = Sp x S m 

= {SCHEDULING, RESCHEDULING) x 
{PRE-PROCESSING, PLACEMENT, 
ALLOCATION, COMPLETION, 
DEALLOCATION) 

If the operational phases (Sp) define the goal of 
SCS (creating a new schedule or adjusting an exist- 
ing one), then the five modes of execution (S m ) de- 
fine the approach that SCS uses to reach its goal. 

SCS's scheduling strategy may be described as a 
sophisticated generate-and-test algorithm. In 
summary, one unprocessed service-request is se- 
lected and translated into blocks, which in turn 
are entered in the appropriate tables. Next, SCS 
analyzes each table to determine when and 
where conflicts are present. It then uses a collec- 
tion of algorithmic, heuristic, and blind-search 
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rules to resolve each conflict. Finally, SCS de- 
cides whether the new partial schedule is "valid" 
(i.e., the current request is successfully sched- 
uled, no previously scheduled job has been dis- 
placed, and the partial schedule is reducible to 
some final schedule) or "invalid". In the latter 
case, SCS restores each modified table to its pre- 
vious state and marks the current request as "un- 
schedulable." This process is repeated until each 
job has been processed, at which point SCS fixes 
a time interval and resource set for each job. 

The key to this strategy is that each intermedi- 
ate partial schedule must be reducible to some fi- 
nal complete schedule such that every job in the 
former is also in the latter. That is, if you arbi- 
trarily fix any one nonfixed block in the partial 
schedule, then one method to reduce it to a final 
schedule must still be available without displac- 
ing any jobs. Reduction is defined in more detail 
in Section 3. 2. 2. 3 on Allocation Mode. Figure 3-5 
shows the state transition diagram of SCS. 


3.2.2. 1 Pre-Processing Mode 

Pre-Processing Mode is the first computational 
state of SCS, the user's input specifications are 
received and translated to ART™ relations. Un- 
like the other four execution modes, Pre- 
Processing Mode is never called explicitly. Rath- 
er, it remains in a wait state until new input is 
received from the user. It then activates, inter- 
rupts the current execution mode, processes the 
new input, and returns to the wait state. 

3. 2.2.2 Placement Mode 

The main computational state of SCS is called 
Placement Mode. In this mode, service-requests 
are translated into blocks, and resource conflicts 
are detected and resolved. Figure 3-6 shows the 
transition diagram for Placement Mode and its 
seven substates: Selection, Block Generation, 

Resolution, Acceptance, Restoration, Rejection, 
and Displacement. 


USER 

INPUT 




Figure 3-5. State transition diagram for SCS. 
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To A llocatio n Mode.. 
I = Ic 


I * Ip, 

j( Go) not scheduled previously 


go deactivated 



Scheduling 

OR 

2 nd -Pass 
Rescheduling 


Figure 3-6. Substrate transition diagram for Placement Mode. 


SCS operates on one service-request at a time 
from the agenda of unprocessed requests. Recall 
that the relative scheduling priority, Tip, of each 
service-request defines a partial order on L, and 
that this partial order determines scheduling or- 
der. In the Selection substate, SCS selects the 
current-service-request (represented by go) at ran- 
dom from the set of requests at the top of the agen- 
da. Though using the maximum duration of each 
request as the second discriminator seems reason- 
able when selecting go, no improvement using this 
approach was observed during system testing. 

The Block Generation substate performs two func- 
tions. First, it checks whether the job correspond- 
ing to go is already present in the partial sched- 
ule. Formally, it checks if 3 (|3e B) (j((3) = J(go)). If 
so, SCS deactivates the request and selects a new 
go* Otherwise, SCS generates Po, the se t of blocks 
defined by go, and sets B' = B u pO- One service- 
request may generate dozens of alternative blocks 
for a job, but these will be reduced to, at most, one 
fixed block in the final schedule. 


In the Resolution substate, SCS detects and re- 
solves any conflicts in B'. This substate is by far 
the most complex component of SCS and is dis- 
cussed in detail in Section 3.3, "Conflicts and 
Resolution." 

For the current-service-request to be successfully 
scheduled, B' must meet two criteria after all con- 
flicts are resolved. First, go must be represented 
by at least one block in B'. Second, every job rep- 
resented by a block in B must also be represented 
in B'. Formally, 3 (PeBO (g(P) = go) a V (PeB) 3 
(P'e BO <j(pO = j(P». If both criteria are met, then 
the new partial schedule is accepted. 

If either of the two criteria are not met — that 
is, either go is not represented in B', or it 
"bumped" a job that had been scheduled in B — 
then the new partial schedule is invalid and the 
previous partial schedule is restored. The next 
state transition is dependent on whether SCS is 
in Scheduling or Rescheduling Phase. In the lat- 
ter case, the Displacement Substate will attempt 
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to displace blocks from B so that oq can be suc- 
cessfully scheduled (see Section 3.2.3 "Reschedul- 
ing Strategy"). If SCS is in Scheduling Phase, or 
if displacement has already been attempted for 
CO, then the Rejection substate deactivates co 
and returns control to the Selection substate. 

3. 2.2.3 Allocation Mode 

When Placement Mode is complete, SCS switches 
to Allocation Mode. Here, the partial schedule 
specified by B is reduced to a final, complete one. 
Each job is assigned a fixed start time and re- 
source set, and its alternative blocks are re- 
moved. 

Just as Placement Mode processes I sequentially 
according to each request's scheduling priority, 
Allocation Mode processes P sequentially accord- 
ing to each table's reduction priority. The higher 
the value of Ttp for a table, the more likely its 
corresponding resource will be in continuous use 
during job execution time. 3 The current-table be- 
ing reduced is denoted po. Note, however, that 
the reduction of po may cause changes in other 
tables not yet reduced (because the same block is 
often present in multiple tables). 

The reduction strategy used by Allocation Mode 
is based loosely on the Fox-Kempf Principle of 
Opportunism. A huge number of complete sched- 
ules may be derivable from one partial schedule, 
B, thus indicating a heuristic reduction strategy. 
Consider, though, that certain jobs in J may be 
represented by only one fixed block (call it pieB) 
in the partial schedule. Because SCS has no op- 
tion on scheduling this job, and because every ef- 
fort must be made to keep resources in continu- 
ous use, the system should try to find another 
block, p2> that can either start when pi ends, or 
end when Pi starts. 

Fixing p2 next to Pi creates a chain of length 
two. SCS's reduction strategy is to first extend 
any existing chains in po as long as possible. 
When no chains are extendible, SCS tries to 
create a new chain from the remaining set of 


nonfixed blocks in pQ. Only "Minimize-Delta" 
blocks are exempt from this process; these are 
fixed as close as possible to their requested start 
times before any attempt at chaining begins. 

When all blocks in B are fixed and unique, Allo- 
cation Mode halts and the final schedule is pre- 
sented to the user. SCS enters Rescheduling 
Phase (if it is not there already) and waits for 
new user input in Conclusion Mode. 

3.2.3 Rescheduling Strateg y 

SCS's rescheduling philosophy is to make adjust- 
ments to the current schedule with as few dis- 
ruptions as possible. If a service-request appears 
on the agenda during Rescheduling Phase — ei- 
ther because the user just issued it, or because 
one of its allocated resources suddenly became 
unavailable, or because it was bumped from the 
final schedule by another job — SCS will first try 
to schedule it without disturbing any existing 
blocks. Failing that, SCS will displace certain 
lower-priority blocks to "squeeze" the new re- 
quest into the schedule. These bumped jobs are, 
in turn, placed on the agenda and rescheduled. 

Certain jobs will naturally increase in priority 
once they become part of the final schedule. On 
the Space Station, for example, the astronauts 
will arrange their personal schedules according 
to the daily job schedule they receive each morn- 
ing. Even a relatively minor job, such as a non- 
critical scientific experiment, may require exten- 
sive preparation time. 

The inertia of a service-request, TTi(a), specifies 
the difficulty of displacing a during Rescheduling 
Phase. Inertia is specified as a nonnegative incre- 
ment to the request's scheduling priority and o' 
cannot bump a unless TTpCaO > 7Cp(a) + 7q(a). 

The Placement Mode of the Rescheduling Phase 
will perform two separate attempts to schedule a 
request on its agenda. During the first pass, this 
mode operates exactly as in Scheduling Phase 
unless, and until, the Rejection substate is 


3. The reason why SCS strives to keep resources in continuous use steins from the Space Station domain. To 
conserve electricity, each device in the Communications and Tracking System is turned off when not in use, 

Alt such devices must undergo a ’power-up procedure” before being switched back into operation, and this pro- 
cedure can be relatively expensive in terms of electricity. 
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reached. Instead of deactivating go, SCS trans- 
fers control to a seventh Placement Mode sub- 
state called Displacement. Here, SCS creates a 
displacement set , Bd (B^BdX for gq . Bd includes 
all blocks in B which (1) conflicted with a block 
PgBo during first-pass Resolution, and (2) have a 
rescheduling inertia less than P's scheduling pri- 
ority. SCS then sets B = B - Bd and returns to 
the Block Generation substate. 

If ao is still unschedulable after the second pass, 
Bd is wholly restored and control is passed to 
the Rejection substate as usual. If go is success- 
fully scheduled, however, then a total restoration 
of the displacement set will be impossible. In- 
stead, SCS will attempt to restore each block in 
Bd individually, beginning with the one having 
the highest inertia. Call the set of unrestorable 
blocks Bd'. SCS will reactivate all service- 
requests corresponding to a block in Bd' and 
place them on the agenda, where they will be re- 
scheduled accordingly. 

The Deallocation Mode, also performed during 
the Rescheduling Phase, is strictly administrative 
in purpose. In Deallocation, SCS sets Pp, the set 
of processed tables, equal to the empty set. This 
ensures that the Allocation Mode, when it is re- 
run, will process and reduce every table in P. 

3.3 Conflicts and Resolution 

Conflicts in scheduling and their resolution are an 
innate part of creating almost any type of sched- 
ule. The following example introduces just how 
SCS addresses such conflicts and resolves them. 


Recall the Staff Meeting scenario of Figure 3-1. 
The first service-request on the agenda, o i, re- 
quests one 20-seat conference room and one vu- 
graph projector for a 3-hour period, beginning at 
either 8:00 AM or sometime between 9:00 and 
9:30 AM. SCS will generate the two blocks de- 
scribed by this request, then skip over G2 be- 
cause its job is already represented in B. 

Now assume that G3 (j(G3) = 'TRAINING '; n(G3) 
= (75, 10)) requests a 20-seat conference room for 
1.5 hours starting sometime between 8:00 and 
8:30 AM (see Figure 3-7). Only ROOM_C seats 
20 people, so this training session will either be 
held in that room or not held at all. 
STAFF_MTG has already reserved ROOM_C for 
most of the morning, but has requested more 
time than it actually needs. The question is 
whether a method exists to satisfy the require- 
ments of both jobs. 

This is the basis of SCS's conflict-resolution 
scheduling strategy. When the new Bq is added 
to B, a number of time intervals will likely have 
a resource reserved for more jobs than the re- 
source can legally support. The goal of the Reso- 
lution substate is to detect and resolve all the 
conflicts that might prevent B from being reduci- 
ble to a complete final schedule. 

The Conflict Set for B is denoted X = (XL- ->Xn) 
where each conflict is an ordered triple: 

Xi = (P, (tl,t 2 ), ¥>. 

Xi may be read "block P cannot be scheduled be- 
tween interval ti to t 2 while all blocks in are 



ft - (b 2 , (900, 930), {b 3 )) 
ft = (bi , (830, 930), {b 3 ]) 
ft = (b3, (800, 1000), (b 1 )) 

- (b3, (930, 1000), (b 2 )) 

x' = (b3, (930, 1000), (b 1 , b 2 }) 


Figure 3-7. STAFF.MTG vs. TRAINING conflict. 
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present in B." For every xi, the n blocks in H'fxi) 
must represent n distinct jobs. 

3.3.1 Conf lic t? a n d D ec ida b ili t y 

A conflict can be detected as follows: add up the 
number of distinct jobs present in a table at any 
time and then check if the sum exceeds the ta- 
ble’s capacity. Note, however, that "table” is not 
one of the parameters in the conflict triplet. Con- 
flicts are a property of blocks alone, and a block 
may be present in more than one table. In fact, 
two conflicts found in different tables are often 
combined to form a third conflict. 

Certain types of conflicts are harmless. Figure 
3-8a shows a two-block table that can clearly be 
reduced to a final schedule, despite the presence 
of an overload at (ti,t2). However, the conflict in 
Figure 3-8b is definitely harmful. One of its two 
blocks will have to be eliminated if the table is to 
be reducible. The first type of conflict can be la- 
beled "safe" and the other "dangerous." 

A question now arises, does a simple algorithm 
exist that decides whether any given % is safe or 
dangerous? Apparently not. While many conflicts, 
such as the two in Figure 3-8, are easily decida- 
ble, some appear to require nothing short of 
trial-and-error. 

SCS classifies conflicts into three categories, X = 
X S u Xg u Xu (see Figure 3-9). Dangerous con- 
flicts (x^Xg) are resolved algorithmically, either 
by restricting the width of (i(x) or removing it en- 
tirely. Similarly, safe conflicts (xeXs) are ignored 
for the moment, although later changes to the 


schedule may cause a safe conflict to become 
dangerous. Any conflict that cannot be easily 
proven safe or dangerous is called "undecidable" 

OteXu). 

3.3.2 Dangerous Conflicts 

A decision as to the type of conflict is basically a 
problem of pattern matching. Templates can be 
defined that describe a certain class of conflict in 
its simplest form. A pattern matcher would then 
try to find matches for these templates in a heav- 
ily crowded schedule. This type of problem is 
well suited for a rule-based implementation such 
as ART™. 

Fortunately, the majority of dangerous conflicts 
fall into three easily defined classes. The most 
common type is a first-order conflict. This conflict 
occurs in table p when the critical times of Z(p) 
blocks overlap each other, and these in turn over- 
lap another block. The four conflicts XI "Z4 Fig- 
ure 3-7, as well as the one in Figure 3-8a, are 
first-order conflicts. 

A simple second-order conflict is shown in Figure 
3- 10b. Here, noncritical block 4 overlaps the criti- 
cal times of blocks 1 through 3, but no first-order 
conflicts are present. Block 5 overlaps block 4 at 
both points tA and tg. Upon examination, it is ap- 
parent that block 5 must either (a) start after tA 
or (b) end before tg if block 4 is to be schedulable. 

Third-order conflicts (see Figure 3- 10c) are close- 
ly related to second-order conflicts, except that in 
this example block 4 is a critical block rather 




(b) 


Figure 3-8. Safe vs. dangerous conflicts. 
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Figure 3-9. SCS conflict classes. 


ts tA tB tE 




first-order conflict 


second-order conflict 


%\ = ( b 3 , (t a, t b), (b i , b 2 }) 


XI = (bs, (tB, tA), {b 1 , b2. b3, b*4 ) ) 


(a) 


(b) 



third-order conflict 

X 1 = (b 5 , (tB, tA), (b 1 , b2.b4)) 

(C) 

Figure 3-10. Dangerous conflict classes recognized by SCS. 
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than a noncritical one. Again, note that no 
first-order conflicts are present and that 
block 5 must start after tA if block 4 is to be 
scheduled. 

Both second- and third-order conflicts have 
t2(%) less than ti(x). It seems strange to say 
that a conflict is present "between 10 AM 
and 9 AM". However, if one considers ti(x) 
to be the latest safe time that P(x) can end, 
and t2(x) to be the earliest safe time that P(x) 
can start, then this order of specifying times 
is consistent for all three conflict classes. 
Note also that the job duration of P(x) must 
be greater than (ti(%) - t2(x)) minutes for any 
conflict to be valid. 

3.3.3 Operations on Conflicts 


As described previously, the presence of a dan- 
gerous conflict simply means that a certain block 
cannot be scheduled concurrently with certain 
other blocks. How such a conflict should be re- 
solved, or even if it should be resolved, is not al- 
ways clear. 

Consider Figure 3-11. This table clearly contains 
a dangerous first-order conflict, x = (2, (ti, t2), 
(1}). Does this mean that block 2 must be re- 
stricted to start after t2? Not necessarily. If 
blocks 1 and 1A are alternatives, that is, j(l) = 
j(lA), two options are available: block 2 can be 
restricted, or block 1 can be removed. Which op- 
tion is "correct" depends on the service-requests 
yet to be processed. 

A dangerous conflict with more than one possible 
resolution is called an open conflict. The Fox- 
Kempf Principle of Least Commitment calls for the 
decision on resolving open conflicts to be delayed as 
long as possible. A closed conflict is one which has 
only one possible resolution, in which case SCS can 
make the necessary adjustment immediately. 

Now consider Figure 3-12 which has two danger- 
ous first-order conflicts: xi and X2* Assume j(lA) 
= j(lB). Both conflicts are open when examined 
separately, but notice that if block 2 is scheduled 
across time t2, then neither block 1A nor IB is 
schedulable. A new closed conflict has appeared 
from the intersection of two open ones: x' = (2, 
(t2, t2), (1A, IB}). 


Figure 3-11. An "open" dangerous conflict. 

Combining two open conflicts in this manner 
yields a compound conflict (represented x'X Com- 
pound conflicts are always dangerous, though they 
may be open or closed. They differ from single con- 
flicts in that two or more blocks in *F(x') may repre- 
sent the same job. A complex set of rules governs 
when and how two conflicts may be combined. 

The criteria for determining whether any conflict, 
single or compound, is open or closed can now be 
addressed. Given x = (p, (ti, t2), V F), if no job in 
'F(x) has an alternative not contained in T(x), 
then x is closed. 

SCS resolves closed conflicts by moving the offend- 
ing block completely out of the conflict interval. 
Specifically, for any closed conflict x = (P, (ti, t2), 
'F), SCS will try to split p into two new blocks: 
one running from t ws (P) to ti(x), the other from 
t2(%) to t we (P). Of course, if a new block is not 
wide enough to support j(P), then it is removed 
from B. 

3.3.4 Undecidable Conflicts and Resolution 

States 

As stated earlier, SCS is unable to make decisons 
concerning certain dangerous conflict classes. 
Most of these occur in tables having an overa- 
bundance of noncritical blocks. Figure 3-13 illus- 
trates one such example. None of the three 
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ts tl t 2 t 3 tE 


I I I 



tc( 1A) { } ix(i B) {} 


71 r 

Xi = (b 2 , (ti, t 2 ), (b i a} ) 

= (b 2 , (t 2> 1 3 ) , {blB}) 

r! = (b?, (U t 2 ), (biA, M) 

Figure 3-12. A "closed" compound conflict. 


known conflict orders are present, but no method 
exists to reduce this table without removing one 
of the 13 blocks. 


schedule to minimize the chance that a later ser- 
vice-request will be precluded unnecessarily. 
However, SCS's first priority is to schedule the 
current service-request, and it might become nec- 
essary to make some restrictive decisions to 
squeeze gq into B. 

The obvious first step is to do nothing about un- 
decidable conflicts until all closed conflicts have 
been detected and resolved. Resolving one closed 
conflict often greatly decreases IX I because it 
may eliminate a block that was part of many oth- 
er conflicts. 

Step two is to safely eliminate an undecidable con- 
flict, either by removing the overload condition 
that is causing it or by converting it into a safe 
one. Simply nudging a block out of a conflict inter- 
val or eliminating it completely, if it has an alter- 
native that is not part of any conflict, often elimi- 
nates an undecidable conflict. SCS uses a set of 
heuristics to choose an effective, relatively nondis- 
ruptive adjustment, then checks if any existing 
conflicts may be combined or closed as a result. 


Although a scheduler should ideally not make 
firm scheduling decisions until absolutely neces- 
sary, SCS requires that all partial schedules be 
reducible at the conclusion of each Resolution 
substate. SCS must, therefore, assume that all 
undecidable conflicts are dangerous. At this 
point, SCS can still heuristically adjust the 


If these methods fail, step three is to do whatev- 
er is required to successfully schedule go, no 
matter what effect this may have on the schedul- 
ing of future requests. SCS checks the most 
promising search paths looking for any successful 
and reducible partial schedule. 

The longer SCS requires to eliminate Xu, the 
less flexibility SCS has to deal with 
later service-requests. Consequently, 
the more conflict classes that are de- 
cidable, the better quality schedule 
SCS will produce. However, the exe- 
cution time of SCS is directly propor- 
tional to the number of decidable con- 
flict classes. 


In the Staff Meeting example dis- 
cussed at the beginning of this sec- 
tion, SCS recognizes four dangerous 
conflicts when G3's blocks are added 
to B (xi to X4i see Figure 3-7). A 
fifth, compound conflict (xiO is gener- 
ated by merging X3 and X4- Three of 
these are closable (%h X2> XlO, and 
the resulting partial schedule is 
shown in Figure 3-14. 



Figure 3-13. An undetectable dangerous conflict. 
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4.0 IMPLEMENTATION rules, and 1000 lines of custom C and LISP code. 

The user supplies an ASCII file containing defini- 
SCS has been implemented on a Digital VAX- tions of the service-requests, tables, and schedul- 
8650 mainframe under the VMS operating sys- ing parameters, 
tern. SCS contains over 300 ART production 


800 1100 1400 1700 



Figure 3-14. The "Staff Meeting" scenario of Figure 3-1 with 
all conflicts resolved. 


A graphical user interface to SCS has 
also been developed using a Digital 
VT341 color terminal (see Figure 4-1). 
Tables and blocks are represented in 
graphical format, with the user hav- 
ing the option of displaying or sup- 
pressing critical times. Mousing on a 
corresponding graphic obtains infor- 
mation on tables or blocks. A column 
of mouse icons along the right edge of 
the screen allows the user to enter 
commands to SCS. 

The user interface may be run as a 
coprocess or parent process to SCS. 
The scheduler generates a series of 
one-line ASCII messages that notifies 
the interface program when a signifi- 
cant action has been performed. 


1 nimTMffTO.min 

CHANGE 

SCALE 



•i HIDE 
CRITICAL 


wmmwmmssssi ■■■■ 

CHANGE 

TABLE 

COliPR 

TABLE 




TABLE 

INFO 

BLOCK 

INFO 

SPACE COMMUNICATIONS SCHEDULER ' ' 


SCH-MODE : Placement 

Table Name: XM0DEMS 
Job Capacity: 9 
Scheduling Priority: 1 

JOB ID: G 

PAUSE 

STATUS: Accept 


EXIT 




Figure 4-1. SCS user interface. 
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These actions include creation of a table, creation 
of a new block, adjustment or deletion of an exist- 
ing block, selection of a new current-service- 
request, or a change in the system's phase or 
mode. The user interface acts on these messages 
sequentially, adjusting the display to reflect the 
new system state. 

5.0 CONCLUSIONS AND FUTURE WORK 

The conflict-resolution scheduling strategy of SCS 
works quite well within SCS’s limited scheduling 
subclass. Empirical data indicates that SCS oper- 
ates in low-order polynomial time for I P I (the 
number of tables) and I J I (the number of distinct 
jobs). It appears, however, to be exponential for 
MA XJk, the maximum capacity of any peP (hence 
the requirement for low-capacity resources). 

Future development work may address variable- 
length job durations ("I need a conference room 
for between three and four hours’), non-reusable 
resources, and resource sets with nonidentical 
time constraints ("I need a conference room for 
two hours, and a vugraph projector for the first 
half-hour"). Another useful feature would be to al- 
low inertia values to be specified as a function of 
time, based on the theory that it is better to re- 
schedule a job ten hours before its scheduled start 
time rather than just ten minutes beforehand. 
SCS may also be translated into C or Ada to im- 
prove speed and facilitate software verification. 
Before any translation can occur, however, an effi- 
cient means for detecting dangerous conflicts is 
needed because SCS will no longer have access to 
ART™’s powerful pattern-matching facility. 

SCS could also be extended to allow temporal re- 
strictions between jobs. For example, a specifica- 
tion could be made that job ji may not begin exe- 
cuting until halts. Restrictions could also be 
specified at the service-request level ("if ji is 
scheduled via a i, then 02 must run concurrently 
with it"), or they could define one job to be con- 
tingent on another ("If ji is scheduled before 
0800 hours, then do not schedule j2"). Allen [9] 
lists 13 possible relationships between time inter- 
vals that could be used as the bases for temporal 
restrictions. 
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